home *** CD-ROM | disk | FTP | other *** search
/ Graphics Plus / Graphics Plus.iso / general / modelers / geomview / sgi.lha / Geomview / man / cat5 / oogl.5 < prev   
Text File  |  1993-11-16  |  41KB  |  1,387 lines
  1.  
  2.  
  3.  
  4. OOGL(5)                              OOGL(5)
  5.  
  6.  
  7. NAME
  8.        OOGL - File formats for OOGL geometric objects
  9.  
  10. NOTE
  11.        The  material  in  this    manual    page  also appears in the
  12.        Geomview    manual.
  13.  
  14. DESCRIPTION
  15.        OOGL File Formats
  16.        *****************
  17.  
  18.        The objects that    you can    load into Geomview are called OOGL objects.
  19.        OOGL stands for "Object Oriented    Graphics Library"; it is the library
  20.        upon which Geomview is built.
  21.  
  22.        There are many different    kinds of OOGL objects.    This chapter gives
  23.        syntactic descriptions of file formats for OOGL objects.
  24.  
  25.        Examples    of most    file types live    in Geomview's `data/geom'
  26.        directory.
  27.  
  28.        Conventions
  29.        ===========
  30.  
  31.        Syntax Common to    All OOGL File Formats
  32.        --------------------------------------
  33.  
  34.        Most OOGL object    file formats are free-format ASCII --- any amount of
  35.        white space (blanks, tabs, newlines) may    appear between tokens (numbers,
  36.        key words, etc.).  Line breaks are almost always    insignificant, with a
  37.        couple of exceptions as noted.  Comments    begin with # and continue to
  38.        the end of the line; they're allowed anywhere a newline is.
  39.  
  40.        Binary formats are also defined for several objects; *Note Binary format::, and the individual object descriptions.
  41.  
  42.        Typical OOGL objects begin with a key word designating object type,
  43.        possibly    with modifiers indicating presence of color information    etc.
  44.        In some formats the key word is optional, for compatibility with    file
  45.        formats defined elsewhere.  Object type is then determined by
  46.        guessing    from the file suffix (if any) or from the data itself.
  47.  
  48.        Key words are case sensitive.  Some have    optional prefix    letters
  49.        indicating presence of color or other data; in this case    the order of
  50.        prefixes    is significant,    e.g. `CNMESH' is meaningful but
  51.        `NCMESH'    is invalid.
  52.  
  53.  
  54.        File Names
  55.        ----------
  56.  
  57.        When OOGL objects are read from disk files, the OOGL library uses the
  58.        file suffix to guess at the file    type.
  59.  
  60.        If the suffix is    unrecognized, or if no suffix is available (e.g. for an
  61.  
  62.  
  63.  
  64. Geometry Center       Mon Nov 15 21:35:41 CST 1993            1
  65.  
  66.  
  67.  
  68.  
  69.  
  70. OOGL(5)                              OOGL(5)
  71.  
  72.  
  73.        object being read from a    pipe, or embedded in another OOGL object), all
  74.        known types of objects are tried    in turn    until one accepts the data as
  75.        valid.
  76.  
  77.  
  78.        Vertices
  79.        --------
  80.  
  81.        Several objects share a common style of representing vertices with
  82.        optional    per-vertex surface-normal and color.  All vertices within an
  83.        object have the same format, specified by the header key    word.
  84.  
  85.        All data    for a vertex is    grouped    together (as opposed to    e.g. giving
  86.        coordinates for all vertices, then colors for all vertices, and so on).
  87.  
  88.        The syntax is
  89.  
  90.        `X  Y  Z'
  91.         (3-D floating-point    vertex coordinates) or
  92.        `X  Y  Z     W'
  93.         (4-D floating-point    vertex coordinates)
  94.  
  95.        optionally followed by
  96.  
  97.        `NX  NY    NZ'
  98.         (normalized    3-D surface-normal if present)
  99.  
  100.        optionally followed by
  101.  
  102.        `R  G  B     A'
  103.         (4-component floating-point    color if present, each component in range
  104.         0..1.  The A (alpha) component represents opacity: 0 transparent, 1
  105.         opaque.)
  106.  
  107.        Values are separated by white space, and    line breaks
  108.        are immaterial.
  109.  
  110.  
  111.        Surface normal directions
  112.        -------------------------
  113.  
  114.        Geomview    uses normal vectors to determine how an    object is shaded.
  115.        The direction of    the normal is significant in this calculation.
  116.  
  117.        When normals are    supplied with an object, the direction of the normal
  118.        is determined by    the data given.
  119.  
  120.        When normals are    not supplied with the object, Geomview computes    normal
  121.        vectors automatically; in this case normals point toward    the side from
  122.        which the vertices appear in counterclockwise order.
  123.  
  124.        On parametric surfaces (Bezier patches),    the normal at point P(u,v)
  125.        is in the direction dP/du cross dP/dv.
  126.  
  127.  
  128.  
  129.  
  130. Geometry Center       Mon Nov 15 21:35:41 CST 1993            2
  131.  
  132.  
  133.  
  134.  
  135.  
  136. OOGL(5)                              OOGL(5)
  137.  
  138.  
  139.        Transformation matrices
  140.        -----------------------
  141.  
  142.        Some objects incorporate    4x4 real matrices for homogeneous object
  143.        transformations.     These matrices    act by multiplication on the right of
  144.        vectors.     Thus, if p is a 4-element row vector representing homogeneous
  145.        coordinates of a    point in the OOGL object, and A    is the 4x4 matrix, then
  146.        the transformed point is    p' = p A.  This    matrix convention is common in
  147.        computer    graphics; it's the transpose of    that often used    in mathematics,
  148.        where points are    column vectors multiplied on the right of matrices.
  149.  
  150.  
  151.        Thus for    Euclidean transformations, the translation components appear in
  152.        the fourth row (last four elements) of A.  A's last column (4th,    8th,
  153.        12th and    16th elements) are typically 0,    0, 0, and 1 respectively.
  154.  
  155.  
  156.        Binary format
  157.        -------------
  158.  
  159.        Many OOGL objects accept    binary as well as ASCII    file formats.
  160.        These files begin with the usual    ASCII token (e.g. `CQUAD')
  161.        followed    by the word `BINARY'.
  162.        Binary data begins at the byte following    the first newline after
  163.        `BINARY'.  White    space and a single comment may intervene, e.g.
  164.  
  165.         OFF    BINARY       # binary-format "OFF" data follows
  166.  
  167.        Binary data comprise 32-bit integers and    32-bit IEEE-format floats, both
  168.        in big-endian format (i.e., with    most significant byte first).  This is
  169.        the native format for 'int's and    'float's on Sun-3's, Sun-4's, and
  170.        Irises, among others.
  171.  
  172.        Binary data formats resemble the    corresponding ASCII formats, with ints
  173.        and floats in just the places you'd expect.  There are some exceptions
  174.        though, specifically in the `QUAD' and `OFF' file formats.
  175.        Details are given in the    individual file    format descriptions.
  176.        *Note QUAD::, and *Note OFF::.
  177.  
  178.        Binary OOGL objects may be freely mixed in ASCII    object streams:
  179.  
  180.         LIST
  181.         { =    MESH BINARY
  182.         ...    binary data for    mesh here ...
  183.         }
  184.         { =    QUAD
  185.          1 0 0     0 0 1     0 1 0    0 1 0
  186.         }
  187.  
  188.        Note that ASCII data resumes immediately    following the last byte    of
  189.        binary data.
  190.  
  191.        Naturally, it's impossible to embed comments inside a binary-format OOGL
  192.        object, though comments may appear in the header    before the beginning of
  193.  
  194.  
  195.  
  196. Geometry Center       Mon Nov 15 21:35:41 CST 1993            3
  197.  
  198.  
  199.  
  200.  
  201.  
  202. OOGL(5)                              OOGL(5)
  203.  
  204.  
  205.        binary data.
  206.  
  207.  
  208.        Embedded    objects    and external-object references
  209.        -----------------------------------------------
  210.  
  211.        Some object types (`LIST', `INST') allow    references to other
  212.        OOGL objects, which may appear literally    in the data stream, be loaded
  213.        from named disk files, or be communicated from elsewhere    via named
  214.        objects.     Gcl commands also accept geometry in these forms.
  215.  
  216.        The general syntax is
  217.  
  218.          <oogl-object>  ::=
  219.          [ "{" ]
  220.              [ "define"    `symbolname' ]
  221.              [ "appearance" `appearance' ]
  222.              [ ["="] `object-keyword' ...
  223.                | "<" `filename'
  224.                | ":" `symbolname' ]
  225.          [ "}" ]
  226.  
  227.        where "quoted" items are    literal    strings    (which appear without the
  228.        quotes),    [bracketed] items are optional,    and | denotes alternatives.
  229.        Curly braces, when present, must    match; the outermost set of curly
  230.        braces is generally required when the object is in a larger context,
  231.        e.g. when it is part of a larger    object or embedded in a    Geomview
  232.        command stream.
  233.  
  234.        For example, each of the    following three    lines:
  235.          { define fred     QUAD 1    0 0  0 0 1  0 1    0  1 0 0 }
  236.  
  237.          { appearance {    +edge }    LIST { < "file1" } { : fred } }
  238.  
  239.          VECT 1    2 0   2    0   0 0    0   1 1    2
  240.        is a valid OOGL object.    The last example is only valid when it is
  241.        delimited unambiguously by residing in its own disk file.
  242.  
  243.        The "<" construct causes    a disk file to be read.     Note that this    isn't a
  244.        general textual "include" mechanism; a complete OOGL object must    appear
  245.        in the referenced file.
  246.  
  247.        Files read using    "<" are    sought first in    the directory of the file which
  248.        referred    to them, if any; failing that, the normal search path (set by
  249.        Geomview's `load-path' command) is used.     The default search looks
  250.        first in    the current directory, then in the Geomview data directories.
  251.  
  252.        The ":" construct allows    references to symbols, created with
  253.        `define'.  A symbol's initial value is a    null object.  When a
  254.        symbol is (re)defined, all references to    it are automatically changed;
  255.        this is a crucial part of the support for interprocess communication.
  256.        Some future version of the documentation    should explain this better...
  257.  
  258.        Again, white space and line breaks are insignificant, and "#" comments
  259.  
  260.  
  261.  
  262. Geometry Center       Mon Nov 15 21:35:41 CST 1993            4
  263.  
  264.  
  265.  
  266.  
  267.  
  268. OOGL(5)                              OOGL(5)
  269.  
  270.  
  271.        may appear anywhere.
  272.  
  273.  
  274.  
  275.        Appearances
  276.        -----------
  277.  
  278.        Geometric objects can have associated "appearance" information,
  279.        specifying shading, lighting, color, wireframe vs. shaded-surface
  280.        display,    and so on.  Appearances    are inherited through object
  281.        hierarchies, e.g. attaching an appearance to a `LIST' means that    the
  282.        appearance is applied to    all the    `LIST''s members.
  283.  
  284.        Some appearance-related properties are relegated    to "material" and
  285.        "lighting" substructures.  Take care to note which properties belong to
  286.        which structure.
  287.  
  288.        Here's an example appearance structure including    values for all
  289.        attributes.  Order of attributes    is unimportant.     As usual, white space
  290.        is irrelevant.  Boolean attributes may be preceded by "+" or "-"    to turn
  291.        them on or off; "+" is assumed if only the attribute name appears.
  292.        Other attributes    expect values.
  293.  
  294.        A "*" prefix on any attribute, e.g. "*+edge" or "*linewidth 2",
  295.        selects "override" status for that attribute.
  296.  
  297.         appearance {
  298.           +face          # draw faces of polygons
  299.           -edge          # don't draw edges of    polygons
  300.           -transparent      # don't attempt transparency (not implemented)
  301.           +normal          # do draw surface-normal vectors
  302.           normscale    .25      # ...    with length .25    in object coordinates
  303.  
  304.           +evert          # do evert polygon normals where needed so as
  305.                   #   to always    face the camera
  306.  
  307.           shading smooth      # or "shading    constant" or "shading flat".
  308.                   # smooth = Gouraud shading; flat = faceted.
  309.  
  310.           linewidth    3      # lines & edges are 3    pixels wide.
  311.  
  312.           material {     # Here's a material definition;
  313.                   # it could also be read from a file as in
  314.                   #  "material < file.mat"
  315.  
  316.           ka  1.0      # ambient reflection coefficient.
  317.           ambient .3 .5    .3 # ambient color (red, green,    blue components)
  318.                   # The    ambient    contribution to    the shading is
  319.                   # the    product    of ka, the ambient color,
  320.                   # and    the color of the ambient light.
  321.  
  322.           kd  0.8      # diffuse-reflection coefficient.
  323.           diffuse .9 1 .4 # diffuse color.
  324.                     # (In "shading constant" mode, the surface
  325.  
  326.  
  327.  
  328. Geometry Center       Mon Nov 15 21:35:41 CST 1993            5
  329.  
  330.  
  331.  
  332.  
  333.  
  334. OOGL(5)                              OOGL(5)
  335.  
  336.  
  337.                     # is colored with the diffuse color.)
  338.  
  339.           ks 1.0      # specular reflection    coefficient.
  340.           specular 1 1 1  # specular (highlight) color.
  341.           shininess  25      # specular exponent; larger values give
  342.                   # sharper highlights.
  343.  
  344.           alpha      1.0      # opacity; 0 = transparent (invisible)
  345.                   # when transparency is enabled.
  346.  
  347.           edgecolor   1    1 0  # line & edge color
  348.  
  349.           normalcolor 0    0 0  # color for surface-normal    vectors
  350.           }
  351.  
  352.           lighting {     # Lighting model
  353.  
  354.           ambient  .3 .3 .3  # ambient light
  355.  
  356.           replacelights      # "Use only the following lights to
  357.                   # illuminate the objects under this
  358.                   # appearance."
  359.                   # Without "replacelights", any lights
  360.                   # are    added to those already in the scene.
  361.  
  362.                   # Now    a collection of    real lights
  363.           light    {
  364.               color  1 .7 .6      # light color
  365.               position    1 0 .5 0  # light position [distant light]
  366.                       # given in homogeneous coordinates.
  367.                       # With fourth    component = 0,
  368.                       # this means a light coming from
  369.                       # direction (1,0,.5).
  370.           }
  371.  
  372.           light    {             # Another light.
  373.               color 1 1    1
  374.               position    0 0 .5 1  # light at finite position ...
  375.               location camera      # specified in camera    coordinates.
  376.                       # (Since the camera looks toward -Z,
  377.                       # this example places    the light
  378.                       # .5 unit behind the eye.)
  379.               #    Possible "location" keywords:
  380.               #     global       light position is in    world coordinates
  381.               #            This is the    default    if no location specified.
  382.               #     camera      position is in the camera's coordinate system
  383.               #     local      position is in the coordinate    system where
  384.               #              the appearance was defined
  385.           }
  386.           }              # end    lighting model
  387.         }              # end    appearance
  388.  
  389.  
  390.        There are rules for inheritance of appearance attributes    when several
  391.  
  392.  
  393.  
  394. Geometry Center       Mon Nov 15 21:35:41 CST 1993            6
  395.  
  396.  
  397.  
  398.  
  399.  
  400. OOGL(5)                              OOGL(5)
  401.  
  402.  
  403.        are imposed at different    levels in the hierarchy.
  404.  
  405.        For example, Geomview installs a    backstop appearance which provides
  406.        default values for most parameters; its control panels install other
  407.        appearances which supply    new values for a few attributes; user-supplied
  408.        geometry    may also contain appearances.
  409.  
  410.        The general rule    is that    the child's appearance (the one    closest    to the
  411.        geometric primitives) wins.  So setting an appearance attribute in an
  412.        object's    definition will    prevent    the viewer controls from affecting that
  413.        object's    display.
  414.  
  415.  
  416.        Object File Formats
  417.        ===================
  418.  
  419.        `QUAD': collection of quadrilaterals
  420.        ------------------------------------
  421.  
  422.        The conventional    suffix for a `QUAD' file is `.quad'.
  423.  
  424.        The file    syntax is
  425.  
  426.            [C][N][4]QUAD  -or-  [C][N][4]POLY        # Key word
  427.            VERTEX  VERTEX  VERTEX  VERTEX  # 4*N vertices for some N
  428.            VERTEX  VERTEX  VERTEX  VERTEX
  429.            ...
  430.  
  431.        The leading key word is `[C][N][4]QUAD' or `[C][N][4]POLY',
  432.        where the optional `C' and `N' prefixes indicate    that each vertex
  433.        includes    colors and normals respectively.  That is, these files
  434.        begin with one of the words
  435.  
  436.        `QUAD' `CQUAD' `NQUAD' `CNQUAD' `POLY'
  437.        `CPOLY' `NPOLY' `CNPOLY'
  438.  
  439.        (but not    `NCQUAD' or `NCPOLY').    `QUAD' and `POLY'
  440.        are synonymous; both forms are allowed just for compatibility with
  441.        ChapReyes.
  442.  
  443.        Following the key word is an arbitrary number of    groups of four
  444.        vertices, each group describing a quadrilateral.     See the Vertex    syntax
  445.        above.  The object ends at end-of-file, or with a closebrace if
  446.        incorporated into an object reference (see above).
  447.  
  448.        A `QUAD BINARY' file format is accepted;    *Note Binary format::.    The
  449.        first word of binary data must be a 32-bit integer giving the number of
  450.        quads in    the object; following that is a    series of 32-bit floats,
  451.        arranged    just as    in the ASCII format.
  452.  
  453.  
  454.        `MESH': rectangularly-connected mesh
  455.        ------------------------------------
  456.  
  457.  
  458.  
  459.  
  460. Geometry Center       Mon Nov 15 21:35:41 CST 1993            7
  461.  
  462.  
  463.  
  464.  
  465.  
  466. OOGL(5)                              OOGL(5)
  467.  
  468.  
  469.        The conventional    suffix for a `MESH' file is `.mesh'.
  470.  
  471.        The file    syntax is
  472.  
  473.         [C][N][Z][4][U][u][v]MESH     # Key word
  474.         NU NV         # Mesh dimensions
  475.                      # NU*NV vertices, in format specified
  476.                      # by initial key word
  477.         VERTEX(u=0,v=0)  VERTEX(1,0)  ... VERTEX(NU-1,0)
  478.         VERTEX(0,1)    ...    VERTEX(NU-1,1)
  479.         ...
  480.         VERTEX(0,NV-1) ... VERTEX(NU-1,NV-1)
  481.  
  482.        The key word is    `[C][N][Z][4][U][u][v]MESH'.
  483.        The optional prefix characters mean:
  484.  
  485.        `C'
  486.         Each vertex    (see Vertices above) includes a    4-component color.
  487.        `N'
  488.         Each vertex    includes a surface normal vector.
  489.        `Z'
  490.         Of the 3 vertex position values, only the Z    component is present; X    and
  491.         Y are omitted, and assumed to equal    the mesh (u,v) coordinate so X
  492.         ranges from    0 .. (Nu-1), Y from 0 .. (Nv-1)    where Nu and Nv    are the    mesh
  493.         dimensions -- see below.
  494.        `4'
  495.         Vertices are 4D, each consists of 4    floating values.  `Z' and
  496.         `4'    cannot both be present.
  497.        `U'
  498.         Each vertex    includes a 3-component texture space parameter.     This is
  499.         not    yet implemented    and should not be used.
  500.        `u'
  501.         The    mesh is    wrapped    in the u-direction, so the
  502.         (0,v)'th vertex is connected to the    (NU-1,v)'th for    all v.
  503.        `v'
  504.         The    mesh is    wrapped    in the v-direction, so the (u,0)'th vertex is
  505.         connected to the (u,NV-1)'th for all u.  Thus a u-wrapped or
  506.         v-wrapped mesh is topologically a cylinder,    while a    uv-wrapped mesh    is a
  507.         torus.
  508.  
  509.        Note that the order of prefix characters    is significant;    a colored,
  510.        u-wrapped mesh is a `CuMESH' not    a `uCMESH'.
  511.  
  512.        Following the mesh header are integers NU and NV,
  513.        the dimensions of the mesh.
  514.  
  515.        Then follow NU*NV vertices, each    in the form given by the header.
  516.        They appear in v-major order, i.e. if we    name each vertex by (u,v)
  517.        then the    vertices appear    in the order
  518.  
  519.         (0,0) (1,0)    (2,0) (3,0) ...     (NU-1,0)
  520.         (0,1) (1,1)    (2,1) (3,1) ...     (NU-1,1)
  521.         ...
  522.         (0,Nv-1)       ...    (NU-1,NV-1)
  523.  
  524.  
  525.  
  526. Geometry Center       Mon Nov 15 21:35:41 CST 1993            8
  527.  
  528.  
  529.  
  530.  
  531.  
  532. OOGL(5)                              OOGL(5)
  533.  
  534.  
  535.        A `MESH BINARY' format is accepted; *Note Binary    format::.  The
  536.        values of NU and    NV are 32-bit integers;    all other values
  537.        are 32-bit floats.
  538.  
  539.  
  540.        Bezier Surfaces
  541.        ---------------
  542.  
  543.        The conventional    file suffixes for Bezier surface files are `.bbp'
  544.        or `.bez'.  A file with either suffix may contain either    type of
  545.        patch.
  546.  
  547.        Syntax:
  548.  
  549.           [ST]BBP -or- [C]BEZ<NU><NV><ND>[_ST]
  550.                # NU, NV are    u- and v-direction
  551.                # polynomial    degrees    in range 1..6
  552.                # ND    = dimension: 3->3-D, 4->4-D (rational)
  553.                # (The '<' and '>' do not appear in the input.)
  554.                # NU,NV,ND are each a single    decimal    digit.
  555.                # BBP form implies NU=NV=ND=3 so BBP    = BEZ333.
  556.  
  557.               #    Any number of patches follow the header
  558.                # (NU+1)*(NV+1) patch control points
  559.                # each 3 or 4 floats    according to header
  560.           VERTEX(u=0,v=0)  VERTEX(1,0) ... VERTEX(NU,0)
  561.           VERTEX(0,1)        ... VERTEX(NU,1)
  562.           ...
  563.           VERTEX(0,NV)       ... VERTEX(NU,NV)
  564.  
  565.                # ST    texture    coordinates if mentioned in header
  566.           `S'(u=0,v=0) `T'(0,0)  `S'(0,NV) `T'(0,NV)
  567.           `S'(NU,0)       `T'(NU,0) `S'(NU,NV)    `T'(NU,NV)
  568.  
  569.                # 4-component float (0..1) R    G B A colors
  570.                # for each patch corner if mentioned    in header
  571.           `RGBA'(0,0)   `RGBA'(0,NV)
  572.           `RGBA'(NU,0)  `RGBA'(NU,NV)
  573.  
  574.        These formats represent collections of Bezier surface patches, of
  575.        degrees up to 6,    and with 3-D or    4-D (rational) vertices.
  576.  
  577.        The header keyword has the forms    `[ST]BBP' or
  578.        `[C]BEZ<NU><NV><ND>[_ST]' (the '<' and '>' are
  579.        not part    of the keyword.
  580.  
  581.        The `ST'    prefix on `BBP', or `_ST' suffix on
  582.        `BEZuvn', indicates that    each patch includes four pairs of
  583.        floating-point texture-space coordinates, one for each corner of    the
  584.        patch.
  585.  
  586.        The `C' prefix on `BEZuvn' indicates a colored patch,
  587.        including four sets of four-component floating-point colors (red, green,
  588.        blue, and alpha)    in the range 0..1, one color for each corner.
  589.  
  590.  
  591.  
  592. Geometry Center       Mon Nov 15 21:35:41 CST 1993            9
  593.  
  594.  
  595.  
  596.  
  597.  
  598. OOGL(5)                              OOGL(5)
  599.  
  600.  
  601.        NU and NV, each a single    digit in the range 1..6, are the
  602.        patch's polynomial degree in the    u and v    direction respectively.
  603.  
  604.        ND is the number    of components in each patch vertex, and    must be
  605.        either `3' for 3-D or `4' for homogeneous coordinates, that
  606.        is, rational patches.
  607.  
  608.        `BBP' patches are bicubic patches with 3-D vertices, so `BBP'
  609.        = `BEZ333' and `STBBP' =    `BEZ333_ST'.
  610.  
  611.        Any number of patches follow the    header.     Each patch comprises a    series
  612.        of patch    vertices, followed by optional (s,t) texture coordinates,
  613.        followed    by optional (r,g,b,a) colors.
  614.  
  615.        Each patch has (NU+1)*(NV+1) vertices in    v-major    order, so that if we
  616.        designate a vertex by its control point indices (u,v) the order is
  617.          (0,0) (1,0) (2,0) ...    (NU,0)
  618.          (0,1) (1,1) (2,1) ...    (NU,1)
  619.          ...
  620.          (0,NV)           ...    (NU,NV)
  621.        with each vertex    containing either 3 or 4 floating-point    numbers
  622.        as specified by the header.
  623.  
  624.        If the header calls for ST coordinates, four pairs of floating-point
  625.        numbers follow: the texture-space coordinates for the (0,0),
  626.        (NU,0), (0,NV), and (NU,NV) corners of the
  627.        patch, respectively.
  628.  
  629.        If the header calls for colors, four four-component (red, green,    blue,
  630.        alpha) floating-point colors follow, one    for each patch corner.
  631.  
  632.        The series of patches ends at end-of-file, or with a closebrace if
  633.        incorporated in an object reference.
  634.  
  635.  
  636.        OFF Files
  637.        ---------
  638.  
  639.        The conventional    suffix for `OFF' files is `.off'.
  640.  
  641.        Syntax:
  642.  
  643.         [C][N][4]OFF    # Header keyword (optional)
  644.         NVERTICES  NFACES  NEDGES    # NEdges not used or checked
  645.  
  646.         X[0]  Y[0]    Z[0]    # Vertices, possibly with colors
  647.                # and/or normals if `COFF' or `NOFF'
  648.         ...
  649.         X[NVERTICES-1]  Y[NVERTICES-1]  Z[NVERTICES-1]
  650.  
  651.                # Faces
  652.                # NV    = # vertices on    this face
  653.                # V[0] ... V[NV-1]: vertex indices
  654.                #         in    range 0..NVERTICES-1
  655.  
  656.  
  657.  
  658. Geometry Center       Mon Nov 15 21:35:41 CST 1993               10
  659.  
  660.  
  661.  
  662.  
  663.  
  664. OOGL(5)                              OOGL(5)
  665.  
  666.  
  667.         NV    V[0] V[1] ... V[NV-1]  COLORSPEC
  668.         ...
  669.                # COLORSPEC continues past V[NV-1]
  670.                # to    end-of-line; may be 0 to 4 numbers
  671.                # nothing: default
  672.                #  integer: colormap    index
  673.                # 3 or 4 integers: RGB[A] values 0..255
  674.                 # 3 or 4 floats: RGB[A]    values 0..1
  675.  
  676.        `OFF' files (name for "object file format") represent collections
  677.        of planar polygons with possibly    shared vertices, a convenient way to
  678.        describe    polyhedra.  The    polygons may be    concave    but there's no
  679.        provision for polygons containing holes.
  680.  
  681.        An `OFF'    file may begin with the    keyword    `OFF'; it's
  682.  
  683.  
  684.  
  685.        recommended but optional, as many existing files    lack this keyword.
  686.  
  687.        Three ASCII integers follow: NVERTICES, NFACES, and
  688.        NEDGES.    Thse are the number of vertices, faces,    and edges,
  689.        respectively.  Current software does not    use nor    check NEDGES; it
  690.        needn't be correct but must be present.
  691.  
  692.        The vertex coordinates follow: dimension    * NVERTICES
  693.        floating-point values.  They're implicitly numbered 0 through
  694.        NVERTICES-1.  dimension is either 3 (default) or    4 (specified by
  695.        the key character `4' directly before `OFF' in the keyword).
  696.  
  697.        Following these are the face descriptions, typically written
  698.        with one    line per face.    Each has the form
  699.         N  VERT1 VERT2 ... VERTN  [COLOR]
  700.        Here N is the number of vertices    on this    face,
  701.        and VERT1 through VERTN are indices into    the list of
  702.        vertices    (in the    range 0..NVERTICES-1).
  703.  
  704.        The optional COLOR may take several forms.  Line    breaks are
  705.        significant here: the COLOR description begins after VERTN
  706.        and ends    with the end of    the line (or the next #    comment).  A
  707.        COLOR may be:
  708.  
  709.        nothing
  710.         the    default    color
  711.        one integer
  712.         index into "the" colormap; see below
  713.        three or    four integers
  714.         RGB    and possibly alpha values in the range 0..255
  715.        three or    four floating-point numbers
  716.         RGB    and possibly alpha values in the range 0..1
  717.  
  718.        For the one-integer case, the colormap is currently read    from the file
  719.        `cmap.fmap' in Geomview's `data'    directory.  Some better
  720.        mechanism for supplying a colormap is likely someday.
  721.  
  722.  
  723.  
  724. Geometry Center       Mon Nov 15 21:35:41 CST 1993               11
  725.  
  726.  
  727.  
  728.  
  729.  
  730. OOGL(5)                              OOGL(5)
  731.  
  732.  
  733.        The meaning of "default color" varies.  If no face of the object    has a
  734.        color, all inherit the environment's default material color.  If    some
  735.        but not all faces have colors, the default is gray (R,G,B,A=.666).
  736.  
  737.        A `[C][N]OFF BINARY' format is accepted;    *Note Binary format::.    It
  738.        resembles the ASCII format in almost the    way you'd expect, with 32-bit
  739.        integers    for all    counters and vertex indices and    32-bit floats for
  740.        vertex positions    (and vertex colors or normals if
  741.        `COFF'/`NOFF'/`CNOFF' format).
  742.  
  743.        Exception: each face's vertex indices are followed by an    integer
  744.        indicating how many color components accompany it.  Face    color
  745.        components must be floats, not integer values.  Thus a colorless
  746.        triangular face might be    represented as
  747.  
  748.         int    int int    int int
  749.         3    17   5     9   0
  750.  
  751.        while the same face colored red might be
  752.  
  753.         int    int int    int int    float float float float
  754.          3    17   5     9   4     1.0   0.0   0.0   1.0
  755.  
  756.  
  757.  
  758.        VECT Files
  759.        ----------
  760.  
  761.        The conventional    suffix for `VECT' files    is `{.vect}.'
  762.        Syntax:
  763.  
  764.         [4]VECT
  765.         NPOLYLINES    NVERTICES  NCOLORS
  766.  
  767.         NV[0] ... NV[NPOLYLINES-1]       # number of vertices
  768.                                # in each polyline
  769.  
  770.         NC[0] ... NC[NPOLYLINES-1]       # number of colors supplied
  771.                                # in each polyline
  772.  
  773.         VERT[0] ...    VERT[NVERTICES-1]  # All the vertices
  774.                                # (3*NVertices floats)
  775.  
  776.         COLOR[0] ... COLOR[NCOLORS-1]  # All the colors
  777.                                # (4*NColors floats, RGBA)
  778.  
  779.        `VECT' objects represent    lists of polylines (strings of connected
  780.        line segments, possibly closed).     A degenerate polyline can be used to
  781.        represent a point.
  782.  
  783.        A `VECT'    file begins with the key word `VECT' or    `4VECT'
  784.        and three integers: NLINES, NVERTICES, and NCOLORS.
  785.        Here NLINES is the number of polylines in the file,
  786.        NVERTICES the total number of vertices, and NCOLORS the
  787.  
  788.  
  789.  
  790. Geometry Center       Mon Nov 15 21:35:41 CST 1993               12
  791.  
  792.  
  793.  
  794.  
  795.  
  796. OOGL(5)                              OOGL(5)
  797.  
  798.  
  799.        number of colors    as explained below.
  800.  
  801.        Next come NLINES    integers
  802.  
  803.         NV[0] NV[1]    NV[2] ... NV[NLINES-1]
  804.  
  805.        giving the number of vertices in    each polyline.    A negative number
  806.        indicates a closed polyline; 1 denotes a    single-pixel point.  The sum
  807.        (of absolute values) of the NV[I] must equal NVERTICES.
  808.  
  809.        Next come NLINES    more integers Nc[i]: the number    of colors in
  810.        each polyline.  Normally    one of three values:
  811.  
  812.        0
  813.         No color is    specified for this polyline.  It's drawn in the    same color
  814.         as the previous polyline.
  815.        1
  816.         A single color is specified.  The entire polyline is drawn in that
  817.         color.
  818.        abs(NV[I])
  819.         Each vertex    has a color.  Either each segment is drawn in the
  820.         corresponding color, or the    colors are smoothly interpolated along the
  821.         line segments, depending on    the implementation.
  822.  
  823.        The sum of the NC[I] must equal NCOLORS.
  824.  
  825.        Next come NVERTICES groups of 3 or 4 floating-point numbers: the
  826.        coordinates of all the vertices.     If the    keyword    is 4VECT then
  827.        there are 4 values per vertex.  The first abs(NV[0]) of them form
  828.        the first polyline, the next abs(NV[1]) form the    second and so on.
  829.  
  830.        Finally NCOLORS groups of 4 floating-point numbers give red,
  831.        green, blue and alpha (opacity) values.    The first NC[0]    of them
  832.        apply to    the first polyline, and    so on.
  833.  
  834.        A VECT BINARY format is accepted; *Note Binary format::.     The
  835.        binary format exactly follows the ASCII format, with 32-bit ints    where
  836.        integers    appear,    and 32-bit floats where    real values appear.
  837.  
  838.  
  839.  
  840.  
  841.        INST Files
  842.        ----------
  843.  
  844.        The conventional    suffix for a `INST' file is `.inst'.
  845.  
  846.        An `INST' applies a 4x4 transformation to another OOGL object.  It
  847.        begins with `INST' followed by these sections which may appear in
  848.        any order:
  849.         geom OOGL-OBJECT
  850.        specifies the OOGL object to be instantiated.  *Note References::, for
  851.        the syntax of an    OOGL-OBJECT.  The keyword `unit' is a
  852.        synonym for `geom'.
  853.  
  854.  
  855.  
  856. Geometry Center       Mon Nov 15 21:35:41 CST 1993               13
  857.  
  858.  
  859.  
  860.  
  861.  
  862. OOGL(5)                              OOGL(5)
  863.  
  864.  
  865.         transform    ["{"] `4x4 transform' ["}"]
  866.        specifies a single transformation matrix.  Either the
  867.        matrix may appear literally as 16 numbers, or there may be
  868.        a reference to a    "transform" object, i.e.
  869.         "<"    file-containing-4x4-matrix
  870.        or
  871.         ":"    symbol-representing-"transform"-object>
  872.  
  873.        Another way to specify the transformation is
  874.  
  875.         transforms
  876.         OOGL-OBJECT
  877.  
  878.        The OOGL-OBJECT must be a `TLIST' object    (list of
  879.        transformations)    object,    or a `LIST' whose members are ultimately
  880.        `TLIST' objects.     In effect, the    `transforms' keyword takes a
  881.        collection of 4x4 matrices and replicates the `geom' object, making
  882.        one copy    for each 4x4 matrix.
  883.  
  884.        If no `transform' nor `transforms' keyword appears, no
  885.        transformation is applied (actually the identity    is applied).  This
  886.        might be    useful,    e.g., for wrapping an appearance around    an
  887.        externally-supplied object.
  888.  
  889.        *Note Transformation matrices::,    for the    matrix format.
  890.  
  891.        There is    no INST    BINARY format.
  892.  
  893.        INST Examples
  894.  
  895.        Here are    some examples of `INST'    files
  896.  
  897.         INST
  898.          unit <    xyz.vect
  899.          transform {
  900.             1 0    0 0
  901.             0 1    0 0
  902.             0 0    1 0
  903.             1 3    0 1
  904.          }
  905.  
  906.         { appearance { +edge  material { edgecolor 1 1 0 } }
  907.         INST geom < mysurface.quad }
  908.  
  909.         {INST transform {: T} geom {<dodec.off}}
  910.  
  911.         { INST
  912.          transforms
  913.              { LIST
  914.               {    < some-matrices.prj }
  915.               {    < others.prj }
  916.               {    TLIST <still more of them> }
  917.  
  918.              }
  919.  
  920.  
  921.  
  922. Geometry Center       Mon Nov 15 21:35:41 CST 1993               14
  923.  
  924.  
  925.  
  926.  
  927.  
  928. OOGL(5)                              OOGL(5)
  929.  
  930.  
  931.          geom
  932.              { # stuff replicated by all the above matrices
  933.               ...
  934.              }
  935.         }
  936.  
  937.  
  938.        LIST Files
  939.        ----------
  940.  
  941.        The conventional    suffix for a `LIST' file is `.list'.
  942.  
  943.        A list of OOGL objects
  944.  
  945.        Syntax:
  946.  
  947.         LIST
  948.         OOGL-OBJECT
  949.         OOGL-OBJECT
  950.         ...
  951.  
  952.        Note that there's no explicit separation    between    the oogl-objects, so
  953.        they should be enclosed in curly    braces ({ }) for sanity.  Likewise
  954.        there's no explicit marker for the end of the list; unless appearing
  955.        alone in    a disk file, the whole construct should    also be    wrapped    in
  956.        braces, as in:
  957.  
  958.            { LIST {    QUAD ... } { < xyz.quad    } }
  959.  
  960.        A `LIST'    with no    elements, i.e. `{ LIST }', is valid, and is
  961.        the easiest way to create an empty object.  For example,    to remove a
  962.        symbol's    definition you might write
  963.  
  964.            { define    somesymbol  { LIST } }
  965.  
  966.  
  967.  
  968.        TLIST Files
  969.        -----------
  970.  
  971.  
  972.        The conventional    suffix for a `TLIST' file is `.grp' ("group")
  973.        or or `.prj' ("projective" matrices).
  974.  
  975.        Collection of 4x4 matrices, used    in the `transforms' section of and
  976.        `INST' object.
  977.  
  978.        Syntax:
  979.  
  980.         TLIST        # key word
  981.  
  982.         <4x4 matrix    (16 floats)>
  983.         ...            # Any number of    4x4 matrices
  984.  
  985.  
  986.  
  987.  
  988. Geometry Center       Mon Nov 15 21:35:41 CST 1993               15
  989.  
  990.  
  991.  
  992.  
  993.  
  994. OOGL(5)                              OOGL(5)
  995.  
  996.  
  997.        `TLIST's    are used only within the `transforms' clause of    an
  998.        `INST' object.  They cause the `INST's `geom' object to
  999.        be instantiated once under each of the transforms in the    `TLIST'.
  1000.        The effect is like that of a `LIST' of `INST's each with    a
  1001.        single transform, and all referring to the same object, but is more
  1002.        efficient.
  1003.  
  1004.        Be aware    that a `TLIST' is a kind of geometry object, distinct from a
  1005.        `transform' object.  Some contexts expect one type of object,
  1006.        some the    other.    For example in
  1007.         INST transform { : MYT } geom { ...    }
  1008.        MYT must    be a transform object, which might have    been
  1009.        created with the    gcl
  1010.         (read transform { define myT 1 0 0 1 ... })
  1011.        while in
  1012.         INST transforms    { : MYTS } geom    { ... }
  1013.         or    INST transforms    { LIST {: MYTS}    {< more.prj} } geom { ... }
  1014.        MYTS must be a geometry object, defined e.g. with
  1015.         (read geometry { define    MYTS { TLIST 1 0 0 1 ... } })
  1016.  
  1017.        A `TLIST    BINARY'    format is accepted.  Binary data begins    with a
  1018.        32-bit integer giving the number    of transformations, followed by    that
  1019.        number of 4x4 matrices in 32-bit    floating-point format.    The order of
  1020.        matrix elements is the same as in the ASCII format.
  1021.  
  1022.  
  1023.  
  1024.        GROUP Files
  1025.        -----------
  1026.  
  1027.        This format is obsolete,    but is still accepted.    It combined the
  1028.        functions of `INST' and `TLIST',    taking a series    of
  1029.        transformations and a single Geom (`unit') object, and replicating
  1030.        the object under    each transformation.
  1031.  
  1032.         GROUP ... <    matrices > ... unit { OOGL-OBJECT }
  1033.  
  1034.        is still    accepted and effectively translated into
  1035.  
  1036.         INST
  1037.          transforms { TLIST ...    <matrices> ... }
  1038.          unit {    OOGL-OBJECT }
  1039.  
  1040.  
  1041.        DISCGRP Files
  1042.        -------------
  1043.  
  1044.        This format is for discrete groups, such    as appear in the theory    of
  1045.        manifolds or in symmetry    patterns.  This    format has its own man page.
  1046.        See discgrp(5).
  1047.  
  1048.  
  1049.        Non-geometric objects
  1050.        =====================
  1051.  
  1052.  
  1053.  
  1054. Geometry Center       Mon Nov 15 21:35:41 CST 1993               16
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060. OOGL(5)                              OOGL(5)
  1061.  
  1062.  
  1063.        The syntax of these objects is given in the form    used in
  1064.        *Note References::, where "quoted" items    should appear literally    but
  1065.        without quotes, square bracketed    ([ ]) items are    optional, and |    separates
  1066.        alternative choices.
  1067.  
  1068.        Transform Objects
  1069.        -----------------
  1070.  
  1071.        Where a single 4x4 matrix is expected --    as in the
  1072.        `INST' `transform' field, the camera's `camtoworld' transform
  1073.        and the Geomview    `xform*' commands -- use a transform object.
  1074.  
  1075.        Note that a transform is    distinct from a    `TLIST', which is a type
  1076.        of geometry.  `TLIST's can contain one or more 4x4 transformations;
  1077.        "transform" objects must    have exactly one.
  1078.  
  1079.        Why have    both?  In many places -- e.g. camera positioning -- it's only
  1080.        meaningful to have a single transform.  Using a separate    object type
  1081.        enforces    this.
  1082.  
  1083.        Syntax for a transform object is
  1084.  
  1085.         <transform>    ::=
  1086.           [    "{" ]          (curly brace,    generally needed to make
  1087.                    the end of the object unambiguous.)
  1088.  
  1089.            [ "transform" ]      (optional keyword; unnecessary if the    type
  1090.                    is determined by the    context, which it
  1091.                    usually is.)
  1092.            [ "define" <name> ]
  1093.                   (defines a transform named <name>, setting
  1094.                    its value from the stuff which follows)
  1095.  
  1096.           <sixteen floating-point numbers>
  1097.                   (interpreted as a 4x4    homogeneous transform
  1098.                  given row by row, intended    to apply to a
  1099.                    row vector multiplied on its    LEFT, so that e.g.
  1100.                    Euclidean translations appear in the    bottom row)
  1101.            |
  1102.           "<" <filename>  (meaning: read transform from    that file)
  1103.            |
  1104.           ":" <name>      (meaning: use    variable <name>,
  1105.                     defined elsewhere; if undefined the    initial
  1106.                     value is the identity transform)
  1107.  
  1108.          [ "}" ]          (matching curly brace)
  1109.  
  1110.        The whole should    be enclosed in { braces    }.  Braces are not essential
  1111.        if exactly one of the above items is present, so    e.g. a 4x4 array of
  1112.        floats standing alone may but needn't have braces.
  1113.  
  1114.        Some examples, in contexts where    they might be used:
  1115.  
  1116.         # Example 1: A gcl command to define a transform
  1117.  
  1118.  
  1119.  
  1120. Geometry Center       Mon Nov 15 21:35:41 CST 1993               17
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126. OOGL(5)                              OOGL(5)
  1127.  
  1128.  
  1129.         # called "fred"
  1130.  
  1131.         (read transform { transform     define    fred
  1132.              1 0 0 0
  1133.              0 1 0 0
  1134.              0 0 1 0
  1135.             -3 0 1 1
  1136.         }
  1137.         )
  1138.  
  1139.         # Example 2:  A camera object using    transform
  1140.         # "fred" for camera    positioning
  1141.         # Given the    definition above, this puts the    camera at
  1142.         # (-3, 0, 1), looking toward -Z.
  1143.  
  1144.         { camera
  1145.             halfyfield 1
  1146.             aspect 1.33
  1147.             camtoworld { : fred    }
  1148.         }
  1149.  
  1150.  
  1151.        cameras
  1152.        -------
  1153.  
  1154.        A camera    object specifies the following properties of a camera:
  1155.  
  1156.        position    and orientation
  1157.         specified by either    a camera-to-world or world-to-camera transformation;
  1158.         this transformation    does not include the projection, so it's typically
  1159.         just a combination of translation and rotation.  Specified as a
  1160.         transform object, typically    a 4x4 matrix.
  1161.        "focus" distance
  1162.         Intended to    suggest    a typical distance from    the camera to the object of
  1163.         interest; used for default camera positioning (the camera is placed    at
  1164.         (X,Y,Z) = (0,0,focus) when reset) and for adjusting    field-of-view when
  1165.         switching between perspective and orthographic views.
  1166.        window aspect ratio
  1167.         True aspect    ratio in the sense <Xsize>/<Ysize>.  This normally should
  1168.         agree with the aspect ratio    of the camera's    window.     Geomview normally
  1169.         adjusts the    aspect ratio of    its cameras to match their associated
  1170.         windows.
  1171.        near and    far clipping plane distances
  1172.         Note that both must    be strictly greater than zero.    Very large
  1173.         <far>/<near> distance ratios cause Z-buffering to behave badly; part of
  1174.         an object may be visible even if somewhat more distant than    another.
  1175.        field of    view
  1176.         Specified in either    of two forms.
  1177.           `fov '
  1178.  
  1179.          is the    field of view -- in degrees if perspective, or linear
  1180.          distance if orthographic -- in    the *shorter* direction.
  1181.           `halfyfield '
  1182.  
  1183.  
  1184.  
  1185.  
  1186. Geometry Center       Mon Nov 15 21:35:41 CST 1993               18
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192. OOGL(5)                              OOGL(5)
  1193.  
  1194.  
  1195.          is half the projected Y-axis field, in    world coordinates (not angle!),
  1196.          at unit distance from the camera.  For    a perspective camera, halfyfield
  1197.          is related to angular field:
  1198.  
  1199.               halfyfield = tan( Y_axis_angular_field / 2 )
  1200.  
  1201.          while for an orthographic one it's simply:
  1202.  
  1203.                   halfyfield = Y_axis_linear_field / 2
  1204.  
  1205.  
  1206.         This odd-seeming definition    is (a) easy to calculate with and
  1207.         (b)    well-defined in    both orthographic and perspective views.
  1208.  
  1209.  
  1210.        The syntax for a    camera is:
  1211.  
  1212.         <camera> ::=
  1213.  
  1214.            [ "camera" ]          (optional keyword)
  1215.         [ "{" ]             (opening brace, generally required)
  1216.          [ "define" <name> ]
  1217.  
  1218.          "<" <filename>
  1219.           |
  1220.          ":" <name>
  1221.           |
  1222.                 (or any    number of the following,
  1223.                  in any    order...)
  1224.  
  1225.          "perspective"    {"0" | "1"}        (default 1)
  1226.                      (otherwise    orthographic)
  1227.  
  1228.          "stereo"    {"0" | "1"}        (default 0)
  1229.                      (otherwise    mono)
  1230.  
  1231.          "worldtocam" <transform> (see transform syntax    above)
  1232.  
  1233.          "camtoworld" <transform>
  1234.                 (no point in specifying    both
  1235.                  camtoworld and    worldtocam; one    is
  1236.                  constrained to    be the inverse of                 the other)
  1237.  
  1238.          "halfyfield" <half-linear-Y-field-at-unit-distance>
  1239.                 (default tan 40/2 degrees)
  1240.  
  1241.          "fov"        (angular field-of-view if perspective,
  1242.                 linear field-of-view otherwise.
  1243.                 Measured in    whichever direction is smaller,
  1244.                 given the aspect ratio.  When aspect ratio
  1245.                 changes -- e.g. when a window is reshaped --
  1246.                 "fov" is preserved.)
  1247.  
  1248.          "frameaspect" <aspect-ratio>  (X/Y) (default 1.333)
  1249.  
  1250.  
  1251.  
  1252. Geometry Center       Mon Nov 15 21:35:41 CST 1993               19
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258. OOGL(5)                              OOGL(5)
  1259.  
  1260.  
  1261.          "near"     <near-clipping-distance>   (default 0.1)
  1262.  
  1263.          "far"       <far-clipping-distance>     (default 10.0)
  1264.  
  1265.          "focus" <focus-distance>      (default    3.0)
  1266.  
  1267.  
  1268.          [ "}" ]          (matching closebrace)
  1269.  
  1270.  
  1271.        Info file: geomview,    -*-Text-*-
  1272.        produced    by texinfo-format-buffer
  1273.        from file: geomview.tex
  1274.  
  1275.  
  1276.  
  1277.        window
  1278.        ------
  1279.  
  1280.        A window    object specifies size, position, and other window-system
  1281.        related information about a window in a device-independent way.
  1282.  
  1283.        The syntax for a    window object is:
  1284.  
  1285.         window ::=
  1286.  
  1287.          [ "window" ]          (optional keyword)
  1288.            [ "{" ]         (curly brace, often required)
  1289.  
  1290.                 (any of    the following, in any order)
  1291.  
  1292.               "size"  <xsize> <ysize>
  1293.                 (size of the window)
  1294.  
  1295.               "position"  <xmin> <xmax>    <ymin> <ymax>
  1296.                 (position & size)
  1297.  
  1298.  
  1299.               "noborder"
  1300.                 (specifies the window should
  1301.                  have no window    border)
  1302.  
  1303.               "pixelaspect"  <aspect>
  1304.                    (specifies the true visual aspect ratio
  1305.                 of a pixel in this window in the sense
  1306.                 xsize/ysize, normally 1.0.
  1307.                 For stereo hardware which stretches the
  1308.                 display    vertically by a    factor of 2,
  1309.                 "pixelaspect 0.5" might    do.
  1310.                 The value is used when computing the
  1311.                 projection of a    camera associated with
  1312.                 this window.)
  1313.  
  1314.            [ "}" ]         (matching closebrace)
  1315.  
  1316.  
  1317.  
  1318. Geometry Center       Mon Nov 15 21:35:41 CST 1993               20
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324. OOGL(5)                              OOGL(5)
  1325.  
  1326.  
  1327.        Window objects are used in the Geomview `window'    and
  1328.        `ui-panel' commands to set default properties for future    windows    or
  1329.        to change those of an existing window.
  1330.  
  1331.  
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346.  
  1347.  
  1348.  
  1349.  
  1350.  
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.  
  1357.  
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367.  
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384. Geometry Center       Mon Nov 15 21:35:41 CST 1993               21
  1385.  
  1386.  
  1387.